STR:

1. Start with sidebar.verticalTabs = true and sidebar.revamp = true.
2. Create several thousand tabs (Ctrl+T).
3. Shrink the window width until the "List all tabs" button goes into the overflow.
4. Click the overflow button and then click "List all tabs".

Expected:
"List all tabs" button does not go into overflow menu (like the Extensions button) or it opens reliably in the overflow menu.

Actual:
"List all tabs" button goes into overflow menu and fails to open with large numbers of tabs. The tab list is not just slow to open, it never opens even after waiting for some time (Windows 11 and Ubuntu 24.04).

The button cannot be manually moved into the overflow menu in Customize mode but still goes there when overflowing.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b17f4d3142eeb0488513b984c8f5113e80101b96&tochange=82dacb5e3821fc0081deed13bd932839d65867e0

Regressed by Bug 1899598.

:sfoster, since you are the author of the regressor, bug 1899598, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

It seems there are 2 questions here:

1. Do we want to put the all tabs button in the overflow menu or try and keep it in the nav-bar when in vertical tabs? (If that is even possible/practical).

2. If it does wind up there, why isn't the sub-menu opening when there are a lot of tabs?

I'd like to focus on question 2 here and try and make that work - independent of any discussion of if we should end up in this state in the first place. If we accept the premise of bug 1918681, it follows that this bug must get resolved also.

:sfoster, next week is the final week of nightly for Fx133. Do you plan on addressing this in the Fx133 cycle?

"List all tabs" button goes into overflow menu and fails to open with large numbers of tabs. The tab list is not just slow to open, it never opens even after waiting for some time (Windows 11 and Ubuntu 24.04).

I wasn't able to reproduce this (on a mac) with a profile with a thousand tabs. The "List all tabs" button opened in the same way (a bit slow) regardless of where it was located in vertical or horizontal tabs.

Kestrel, can you confirm that you only experienced the issue with opening the "List all tabs" list when it was moved to the overflow list, versus opening it elsewhere? Are you doing this very early on browser restart?

When opening the standalone "List all tabs" button outside the overflow menu, it can be slow to load and make the browser unresponsive but it always opens in the end. When opening from inside the overflow menu, it uses a slide animation that seems to time out and give up when it takes too long. Faster hardware requires more tabs for it to occur. It can happen with fewer tabs when they all have different icons.

(In reply to Donal Meehan [:dmeehan] from comment #3)

:sfoster, next week is the final week of nightly for Fx133. Do you plan on addressing this in the Fx133 cycle?

:sclements, where did we land with this? AFAICT, we don't have a path forward yet and are likely not going to get a fix into fx133, is that correct?

(In reply to Sam Foster [:sfoster] (he/him) from comment #6)

(In reply to Donal Meehan [:dmeehan] from comment #3)

:sfoster, next week is the final week of nightly for Fx133. Do you plan on addressing this in the Fx133 cycle?

:sclements, where did we land with this? AFAICT, we don't have a path forward yet and are likely not going to get a fix into fx133, is that correct?

Yes, since this looks like an edge case (and there's already existing issues with the list all tabs with thousands of tabs per comment 5), we'll look into it for 134.

(In reply to Kestrel from comment #5)

When opening the standalone "List all tabs" button outside the overflow menu, it can be slow to load and make the browser unresponsive but it always opens in the end. When opening from inside the overflow menu, it uses a slide animation that seems to time out and give up when it takes too long. Faster hardware requires more tabs for it to occur. It can happen with fewer tabs when they all have different icons.

Can you create a performance profile with the profiler? I am struggling to reproduce this.

This can affect Firefox 131 and 132 as well since bug 1918681 allowed the button to be movable without vertical tabs.

The large number of tabs is probably related to bug 1820171.

Performance profile with 215 tabs showing 1 second of jank attempting to open list before failure:
https://share.firefox.dev/3Uner34

May be easier to reproduce in a VM with limited resources.

(In reply to Kestrel from comment #10)

Performance profile with 215 tabs showing 1 second of jank attempting to open list before failure:
https://share.firefox.dev/3Uner34

May be easier to reproduce in a VM with limited resources.

Thank you, this is helpful. Out of 751 samples in the hang in that profile, 518 (so roughly 2/3) are going on creating/escaping/parsing data URIs for images. And in fact, if I'm not misreading the profile (possible!), all of that is exactly one image, not even multiple ones (because I'm seeing time spent sequentially at 1 depth in the frame tree to first add the URI and then load the image).

Do you just have 1 tab in that set of 215 with like a giant data URI as favicon and/or URI, perhaps?

(obviously it'd be nice if we handled that better but it would be nice to confirm if that is actually the problem)

Creating the DOM for the 215 rows is only taking about 100ms (judging by some preference read markers for which I'll shortly file another bug...) which although not super fast doesn't look like it'd cause the issues here.

(In reply to Kestrel from comment #10)

1 second of jank attempting to open list before failure

So fwiw, the profile shows us spending a long time processing mousedown, and then when the click registers, that actually causes the panel to hide because the target of the click doesn't appear to require keeping the panel open. This bit is kind of confusing because I can't reproduce, but it's not clear to me why this doesn't just break reliably. Even if I insert a 1 second busy-loop in the processing of the mousedown that opens the view, I can't reproduce. It looks like for me the target of the click is the <panel> instead of the toolbarbutton (presumably because it moves out of the way by the time that the mouseup happens because my clicking is too slow, or something).

It looks like the mousedown handling is something specific to the list-all-tabs panel, implemented in bug 1489124. :-\

I think we can just stick closemenu="none" on the toolbarbutton, or type=menu or something (but that might break other things). Will create a try build and ask you to test if I can't get this to repro locally.

Oh, I found a way that makes this easy to repro: just use the keyboard to open the list all tabs button inside the overflow panel. That reproduces irrespective of the number of tabs. I've confirmed that closemenu=none fixes this.

Still curious about the performance aspect of this (so will leave needinfo for that) although strictly speaking that's probably a different bug.

This just mirrors markup we already have on e.g. the library button.

https://hg.mozilla.org/mozilla-central/rev/6123cdfe55f0

(In reply to :Gijs (he/him) from comment #11)

Do you just have 1 tab in that set of 215 with like a giant data URI as favicon and/or URI, perhaps?

The majority of tabs in that performance profile are bugzilla.mozilla.com and it reproduces in a clean profile, more details in Bug 1820171 Comment 10.

I was able to reproduce the issue on an affected Firefox Nightly build from 2024-10-10, using Ubuntu 22.04 and Windows 11, while following the steps described in Comment 0. I was also able to reproduce it on macOS 14.7 with the steps from Comment 13.
Verified as fixed using Firefox 133.0b9 on Ubuntu 22.04, Windows 11 and macOS 14.7. "List all tabs" button can be open from overflow menu with large numbers of tabs (both click and keyboard).
Please note that "List all tabs" button still goes into overflow menu.